Summary

Fixes DIG-Network/dig_ecosystem#187: digstore collection mint --collection <collection.json> rejected every CHIP-0007-conformant collection.json with error: --collection is not a valid definition: missing field 'trait_type' (dkackman, live user, hit this multiple times).

Root cause: Collection.attributes / CollectionRef.attributes (crates/digstore-chain/src/collection.rs / metadata.rs) reused the NFT-item Attribute struct (serde field trait_type) for collection-level attributes too. Per CHIP-0007, collection attributes (icon/banner/website/etc) use the field type, not trait_type — NFT item attributes correctly use trait_type. The golden test vectors baked in the wrong (trait_type) format for collection attributes, so CI stayed green on a non-conformant reader.

Fix:

• New CollectionAttribute struct: #[serde(rename = "type", alias = "trait_type")] pub kind: String + value: String. Serializes as type going forward; on READ also accepts the legacy trait_type spelling so already-emitted DIG collection.json keeps parsing (§5.1 back-compat, never reject older input).
• Collection.attributes and CollectionRef.attributes now use Vec<CollectionAttribute>. NFT-item Attribute (Chip0007Metadata.attributes, ManifestItem.attributes) is untouched — still trait_type.
• Corrected the golden CHIP-0007 JSON test vectors in collection.rs/metadata.rs (they previously pinned the wrong trait_type shape for collection attributes).
• SPEC.md §11: new normative section documenting the two attribute shapes byte-level, with examples.

Tests (TDD):

• digstore-chain unit tests: a conformant {"type":...} collection attribute parses; the legacy {"trait_type":...} alias still parses; a collection.json with the type field parses into Collection; NFT-item attributes still reject a type-only field (still require trait_type — the two shapes stay distinct).
• digstore-cli integration tests (cli_assets.rs): collection_mint_accepts_chip0007_type_attribute reproduces dkackman's exact command shape — before the fix this failed at exit 2 ("not a valid definition"/trait_type); after the fix it parses and fails only on DID ownership (exit 4, no real DID under the offline mock) — proving the parse bug is gone. collection_mint_accepts_legacy_trait_type_collection_attribute proves back-compat.
• Verified end-to-end against the installed binary (cargo install --path crates/digstore-cli --force --locked) with dkackman's exact collection mint --collection <conformant> --manifest ... --did ... --dry-run shape: no longer fails on parsing; only fails on DID ownership under the mock (expected, no live chain). Confirmed the legacy trait_type collection.json also still parses on the installed binary.

Version bump: patch (0.9.0 → 0.9.1) — backwards-compatible bug fix (fix:), no breaking change; the read side gained a back-compat alias, the write side output shape is corrected but was never conformant/consumed correctly before.

Test plan

• cargo test -p digstore-chain --lib — 203 passed, 0 failed
• cargo test -p digstore-cli --test cli_assets — 17 passed, 0 failed (incl. 2 new regression tests)
• cargo test --workspace (excl. wasm guest target) — all green, 0 failures
• cargo fmt --all -- --check — clean
• cargo clippy -p digstore-chain -p digstore-cli --all-targets --all-features -- -D warnings — clean
• Guest wasm build prereq (cargo build -p digstore-guest --target wasm32-unknown-unknown --release)
• cargo install --path crates/digstore-cli --force --locked + manual installed-binary repro of dkackman's exact command (both type and legacy trait_type collection.json)

Cross-repo follow-up (for the orchestrator — not in this PR)

Per dig_ecosystem#187, checked whether other repos emit collection attributes with the same bug:

• hub.dig.net NFT-collection studio (#122/#139) and create-dig-app NFT template (#121): need a targeted check of their collection-metadata emit code for a trait_type-on-collection-attribute bug — not checked in this digstore-only PR (single-writer per repo).
• docs.dig.net: needs the same type-vs-trait_type correction reflected in the collection-metadata protocol docs (this PR's SPEC.md §11 is the source text to mirror).